Dear All,

This Ethernet Mac IP core from opencores.org (author: Igor Mohor) has worked fantastically for us for quite a few years until a possible bug surfaced when we tested it under extreme work load conditions recently. The symptom of the possible bug and the scenario in which the bug occurs are described as follows.

In the section "Rx Buffer Description" of the IP core's Spec, it is documented that "The Ethernet IP Core reads the Rx BD. If it is marked as empty, it starts receiving frames. The Ethernet receive function receives an incoming frame nibble per nibble. After the whole frame has been received and stored to the memory, the receive status is written to the BD. An interrupt might be generated (if enabled). Then the BD address is incremented and the next BD loaded. If the new BD is marked as empty, another frame can be received; otherwise the operation stops." Our understanding about this paragraph is that when the current Rx BD is empty, the Mac will enable normal receiving operation, otherwise, it will wait until Rx BD is empty, however, ITS SENDING OPERATION SHALL NOT BE AFFECTED BY THE "Rx BD not empty"STATUS; and if a new incoming data frame is received during this "Rx BD not empty"time, it will simply be discarded.

However, in our extreme load test, when the current Rx BD is NOT EMPTY AND when new data is RECEIVED, the Mac will occasionally corrupt the Tx data, which is supposed to be independent of the Rx data, by copying the Rx data to the Tx data, and in some cases even lead to the collapse of the Mac by preventing any data to be sent afterwards.

A test could be easily set up as follows. Using only 1 Tx BD and only 1 Rx BD, and the Rx and Tx data are saved in two separate memory locations. The Mac is controlled to continuously send Tx data at a fixed time interval, while at the same time continuously receiving Rx data frames but taking NO actions on the Rx data and this makes the Rx BD NOT EMPTY after the first data frame is received. Using a software tool for grabbing the Tx data, we quickly find that the Tx data becomes the Rx data even though the two have nothing to do with each other, and sometimes stops getting the Tx data.

This strange behavior of the Mac we find in the test is somewhat different from what the spec describes, and it has puzzled us for quite a few days. We would sincerely appreciate it if you could help us in figuring out the root of the problem.

Hello

Can you give me your contact or email adress so i can ask you few thing i am also trying to use Ethernet IP MAC for my project hope you can provide with a grate help

Best regards

Abdullah Najam